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EXAMINER'S ANSWER 

This is in response to the appeal brief filed 8/03/201 1 appealing from the Office action 
mailed 7/19/2011. 

(1) Real Party in Interest 

A statement identifying by name the real party in interest is contained in the brief. 

(2) Related Appeals and Interferences 

The examiner is not aware of any related appeals, interferences, or judicial 
proceedings which will directly affect or be directly affected by or have a bearing on the 
Board's decision in the pending appeal. 

(3) Status of Claims 

The statement of the status of claims contained in the brief is correct. 

(4) Status of Amendments After Final 

The appellant's statement of the status of amendments after final rejection 
contained in the brief is correct. 

(5) Summary of Claimed Subject Matter 

The summary of claimed subject matter contained in the brief is correct. 

(6) Grounds of Rejection to be Reviewed on Appeal 

The appellant's statement of the grounds of rejection to be reviewed on appeal is 
correct. 

(7) Claims Appendix 

The copy of the appealed claims contained in the Appendix to the brief is correct. 
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(8) Evidence Relied Upon 



US 20040022237 A1 



Elliott et al 



02/06/2003 



US 20020003779 A1 



Szabo 



01/10/2002 



US Patent #5781 532 



Watt 



07/14/1998 



US 20040252686 A1 



Hooper et al 



1 2/1 6/2004 



RFC 3550 



Schulzrinne et al. July 2003 



(9) Grounds of Rejection 

The following ground(s) of rejection are applicable to the appealed claims: 
Claims 1-6 and 9-33 are rejected under 35 U.S.C. 112, first paragraph, as failing 
to comply with the written description requirement. The claim(s) contains subject matter 
which was not described in the specification in such a way as to enable one skilled in 
the art to which it pertains, or with which it is most nearly connected, to make and/or use 
the invention. 

Claim 1 recites the limitation "each of said network paths being associated with 
respective first gateway egress interfaces and a second gateway system IP address". 
There is insufficient support in the specification for this limitation in the claim. 

Note that Appellant stated during telephone interview that the support of this 

limitation is in page 6, line 1 8-31 , which reads as follows: 

Packets traveling to a destination gateway can follow different paths based on the port 206x 
chosen for the specific RTP flow. The MBCAC algorithm assumes that the selection of a port 206x for an 
incoming call request is under the control of a call controller in the gateway. Hence, the MBCAC algorithm 
keeps separate admission policies for the paths from different ports to the same destination gateway. It is 
also assumed that multiple calls going from a particular port to the same destination gateway follows the 
same path, i.e., there is no load balancing within the network other than 25 provided by the gateways 
through the selection of an egress port. This assumption can be satisfied if the gateways use the system 
IP address of the destination gateway as opposed to the IP addresses of its ports. In this framework, load 
balancing is supported by controlling the egress port at the source gateway (i.e., first gateway 114). Since 
each egress port would map into a unique path in the IP network 118, the load from source gateway 114 
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to a destination gateway (i.e., second gateway 116) can be partitioned into different paths, resulting in 
load sharing in the network 

However, the above cited text does not disclose the claim limitation "each path 

of said network paths being associated with respective first gateway egress interfaces" 

in claim 1 . Note this claim limitation suggests that each path may be associated with 

more than one egress interfaces, and the specification does not have the support for 

this limitation. 

Claims 2-6 and 9-33 are rejected because they depend from claim 1 . 

Claim 31 recites the limitation "using all of the network congestion parameters". 
There is insufficient support in the specification for this limitation in the claim. 

Note that Appellant argues the support is in "on Pg. 9, Lines 13 - 16 of Appellants' 
application, which discusses an admission control algorithm that is used to determine if there is an 
uncongested path from the first gateway to the second gateway (i.e., looking at more than one, and 
possibly all, of the paths from the first gateway to the second gateway)." 

Page 9 line 1 3-1 6 reads "Next, first gateway 114 consults with the admission control 
algorithm to see if there is a path to the second gateway 116 that is not congested. If first gateway 1 14 is 
1 5 unable to find an uncongested path to second gateway 1 1 6 it sends an error message at step 41 4 to 
the soft switch 112...". 

The cited text does not disclose "all of the network congestion parameters". 
Claim 32 has the same problem because it depends from claim 31 . 
For purpose of continuation of the prosecution, the claims will be interpreted as 
best understood. 
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Claims 1, 3, 5, 14-15, 18, 23, 26 and 33 are rejected under 35 U.S.C. 103(a) as 
being unpatentable over Elliott et al (US 20040022237, hereinafter Elliott) in view of 
Szabo (US 20020003779 A1). 

For claim 1 , Elliott discloses a method for determining whether to accept a new 
call (a call between phone 102 and phone 120, FIG. 1) to be routed from a first gateway 
(gateway 1 08 of FIG. 1 or 21 B; or SS7 Gateway 208 of FIG. 2A) to a second gateway 
(gateway 1 10 of FIG. 1 or 21 B; or SS7 Gateway 208 of FIG. 2A) in an IP network (VoIP, 
[0453] and FIG. 1), comprising the steps of: 

obtaining, at the first gateway, information indicative of to the quality of service 
("latency or packet loss", [0099] in view of Fig. 21 B) of voice calls being transmitted from 
the first gateway to a second gateway via a plurality of network paths between the first 
gateway and the second gateway (data network 1 12 of FIG. 1 or 21 B that has a plurality 
of network paths between the two gateways); 

determining, using at least a portion of said information, a plurality of congestion 
status parameters indicative of respective congestion statuses of the network paths 
("latency or packet loss", [0099] in view of Fig. 21 B); and 

Elliott does not specifically disclose determining, using at least one of the 
congestion status parameters, whether to accept the new call into the network at the 
first gateway for transmission toward the second gateway via one of the network paths, 
each of said network paths being associated with respective first gateway egress 
interfaces and a second gateway system IP address. 
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In the same field of endeavor, Szabo discloses determining, using at least one of 
the congestion status parameters, whether to accept the new call into the network at the 
first gateway for transmission toward the second gateway via one of the network paths 
("at least one performance indicator value read from the RTCP mechanism does not 
exceed a pre-set threshold value, the call is accepted", [0028]), each of said network 
paths being associated with respective first gateway egress interfaces and a second 
gateway system IP address (suggested by "a method is described in B. Thompson et al. 
"Tunnelling Multiplexed Compressed RTP", Internet Draft, March 2000, Work in 
Progress, wherein a multitude of RTP/UDP/IP packets are compressed and multiplexed 
into a so-called PPP packet", [0005]; note that a UDP/IP tunnel is a path be associated 
with the IP address and egress port of each of two end points of the tunnel). 

Therefore, it would have been obvious to a person of ordinary skill in the art at 
the time of the invention to apply Szabo's teaching above to the gateways disclosed by 
Elliott for the benefit of ensuring "a transmission path with acceptable transmission 
quality" ([0008] of Szabo). 

For claim 14, Elliott discloses an apparatus (soft switch 204 in FIG. 2 and 3, with 
circuit being the means for implementing logic in the soft switch) comprising a first 
gateway for interfacing voice call data from a public switch telephone network to an 
Internet Protocol network; said first gateway further comprising: 

for determining whether to accept a new call to be routed from a first gateway 
(gateway 1 08 of FIG. 1 or 21 B; or SS7 Gateway 208 of FIG. 2A) to a second gateway 
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(gateway 1 10 of FIG. 1 or 21 B; or SS7 Gateway 208 of FIG. 2A) in an IP network (VoIP, 
[0453] and FIG. 1), comprising the steps of: 

a first circuit for passing the voice call data to the internet protocol network (the 
Soft Switch 204 in FIG. 2B); 

a second circuit for polling the internet protocol network about traffic information 
transmitted therein (the Soft Switch 304 in FIG. 2B); and 

a third circuit for: calculating, based on the received quality-of-service 
information, a plurality of congestion status parameters associated with the respective 
network paths between the first gateway and the second gateway, wherein the 
congestions status parameters are indicative of respective congestion statuses of the 
network paths (the circuit in the first gateway responsible for calculating quality-of- 
service information such as ("latency or packet loss", [0099]); and 

obtaining, at the first gateway , information indicative of to the quality of service 
("latency or packet loss", [0099] in view of Fig. 21 B) of voice calls being transmitted from 
the first gateway to a second gateway via a plurality of network paths between the first 
gateway and the second gateway (data network 1 1 2 of FIG. 1 or 21 B that has a plurality 
of network paths between the two gateways); and 

determining, using at least a one of the congestion status parameters_("latency or 
packet loss", [0099] in view of Fig. 21 B). 

Elliott does not specifically disclose determining, using at least one of the 
congestion status parameters, whether to accept the new voice call into the network at 
the first circuit for transmission toward the second gateway via one of the network paths 
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In the same field of endeavor, Szabo discloses determining, using at least one of 
the congestion status parameters, whether to accept the new call into the network at the 
first gateway for transmission toward the second gateway via one of the network paths 
("at least one performance indicator value read from the RTCP mechanism does not 
exceed a pre-set threshold value, the call is accepted ", [0028]). 

Therefore, it would have been obvious to a person of ordinary skill in the art at 
the time of the invention to apply Szabo's teaching above to the gateways disclosed by 
Elliott when determining whether to accept a new call or not to ensure the new call will 
function properly and QoS condition of the network is satisfied. 

As to claim 23, Elliott in view of Szabo claim 1 , Elliott is silent on accepting the 
new call into the IP network at the first gateway for transmission toward the second 
gateway via one of the network paths, wherein the new call is accepted into the IP 
network in the case of the congestion status parameter associated with the one of the 
network paths not exceeding an upper threshold. 

In the same field of endeavor, Szabo discloses accepting the new call into the IP 
network in the case of said parameter not exceeding an upper threshold ("at least one 
performance indicator value read from the RTCP mechanism does not exceed a pre- 
set threshold value, the call is accepted", [0028]; note that RTCP is a protocol for the 
IP network). 

Therefore, it would have been obvious to a person of ordinary skill in the art at 
the time of the invention to apply Szabo's teaching above to the gateways disclosed by 
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Elliott when determining whether to accept a new call or not to ensure the new call will 
function properly and QoS condition of the network is satisfied. 

As to claim 3, Elliott in view of Szabo discloses the method of claim 23, Elliott is 
silent on said new call is not accepted into the IP network in the case of the congestion 
status parameter associated with the one of the network paths exceeding the upper 
threshold. 

Szabo further discloses said new call is not accepted into the IP network in the 
case of the congestion status parameter associated with the one of the network paths 
exceeding the upper threshold ("one performance indicator value exceeds a pre-set 
threshold value, the IP telephony gateway rejects the call in a step 209", [0028]; note 
that the performance indicator is a congestion status parameter). The motivation of 
combination is the same. 

Therefore, it would have been obvious to a person of ordinary skill in the art at 
the time of the invention to reject a new call in order to reduce the network congestion. 

As to claim 5, Elliott in view of Szabo discloses the method of claim 1 , Elliott 
further discloses wherein the obtained information comprises, for each of at least one of 
the network paths, a delay of received packets transmitted from the first gateway to the 
second gateway via the network path (unacceptable latency, [1493], line 4). 

As to claim 15, Elliott in view of Szabo discloses claim 14, Elliott further 
discloses said first circuit further comprises one or more Ethernet cards ("Soft switches 
204a, 204b and 204c are connected ... via redundant Ethernet switches", [0568], which 
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suggest Ethernet interfaces with software switches as the first circuit) that are 
connected to the Internet protocol network. 

As to claim 18, Elliott in view of Szabo discloses claim 14, Elliott further 
discloses the third circuit determining whether the new voice call is to be accepted into 
the internet protocol network via the first circuit, by comparing each of at least one of the 
congestion status parameter to at least one thresholds (Packet Loss Threshold, Table 
147 - continued, page 85, where packet loss values can be used as the thresholds for 
determining if the new voice call is to be accepted or not). 

As to claim 26, Elliott in view of Szabo discloses claim 1 , wherein determining 
whether to accept the new call into the network at the first gateway is made using call 
control logic (as discloses in the parent claim 1), wherein the call control logic is 
updated using the congestion status parameters (this limitation is the same as the last 
paragraph of claim 1 in that the call control logic is the one that the determining is based 
on). 

As to claim 33, Elliott in view of Szabo claim 1 , wherein determining whether to 
accept the new call into the network at the first gateway comprises: 

for each of at least one of the network paths, updating a call admission control 
policy for the network path based on the congestion status parameter determined for 
the network path; and determining whether to accept the new call into the network at the 
first gateway based on the updated call admission control policy (as disclosed by the 
parent claims 1 ; note accepting the new call "using at least one of congestion status 
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parameter" is updating a call admission control policy for the network path based on the 
congestion status parameter). 

Claims 4, 6-10, 19-22, 24-25 and 27-32 are rejected under 35 U.S.C. 103(a) as 
being unpatentable over Elliott in view of Szabo, further in view of Schulzrinne et al., 
ITEF RFC 3550, July 2003 (hereinafter RFC 3550). 

As to claim 4, Elliott in view of Szabo discloses the method of claim 1 , but is 
silent on the information obtained is a number of send packets to said second location 
via the network path, wherein the number of sent packets comprises a number of lost 
packets, a number of late packets and a number of received packets. 

RFC 3550 discloses the information obtained is a number of packets sent to said 
second location via the network path (Line 1 of the paragraph for "Sequence number: 
16 bits", Page 14, where lost packets are those with missing sequence number), 
wherein the number of sent packets comprises a number of lost packets, a number of 
late packets (Line 1 of the paragraph for "Sequence number: 16 bits", Page 14, where 
late packets inherently are packets that have been sent, but have not been received 
according to their sequence numbers) and a number of received packets (sequence 
number provides information on a number of received packets). 

Therefore, it would have been obvious to a person of ordinary skill in the art at 
the time of the invention to apply the teaching of RFC 3550 above to the system 
disclosed by Elliott in view of Szabo for the benefit of getting detailed information 
regarding network operation. 



Application/Control Number: 10/657,864 Page 13 

Art Unit: 2462 

As to claim 6, Elliott in view of Szabo discloses the method of claim 1 , but is 
silent on the information obtained is a delay variation (variation in the delay, Line 5 of 
last paragraph in Page 44) of received packets transmitted from said first location to 
said second location via the network path. 

RFC 3550 further discloses wherein the information obtained is a delay variation 
(variation in the delay in RTCP packet, last paragraph in Page 44) of received packets 
transmitted from said first location to said second location via the network path. 

Therefore, it would have been obvious to a person of ordinary skill in the art at 
the time of the invention to apply the teaching of RFC 3550 above to the system 
disclosed by Elliott in view of Szabo for the benefit of getting detailed information 
regarding network operation. 

As to claim 7, Elliott in view of Szabo discloses the method of claim 1 , but is 
silent on the information is obtained on a periodic basis 

RFC 3550 further discloses the information is obtained on a periodic basis 
("based on periodic transmission", first paragraph in Page 19). 

Therefore, it would have been obvious to a person of ordinary skill in the art at 
the time of the invention to apply the teaching of RFC 3550 above to the system 
disclosed by Elliott in view of Szabo for the benefit of getting detailed information 
regarding network operation. 

As to claim 8, Elliott in view of Szabo discloses the method of claim 1 , but is 
silent on the information is obtained on an exception basis using an immediate report. 
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RFC 3550 further discloses the information is obtained on an exception basis 
using an immediate report (Receiver report, first line of Section 6.4 in Page 35). The 
motivation of combination is the same as described in the parent claim above. 

Therefore, it would have been obvious to a person of ordinary skill in the art at 
the time of the invention to apply the teaching of RFC 3550 above to the system 
disclosed by Elliott in view of Szabo for the benefit of getting detailed information 
regarding network operation. 

As to claim 9, Elliott in view of RFC 3550 and Szabo discloses the method of 
claim 1 , but is silent on the parameter including packet lost ratio. 

RFC 3550 further discloses wherein the parameter include packet lost ratio 
(packet lost ratio, Line 1 of 3 rd paragraph of Section 6.4.4, Page 43). 

Therefore, it would have been obvious to a person of ordinary skill in the art at 
the time of the invention to apply the teaching of RFC 3550 above to the system 
disclosed by Elliott in view of Szabo for the benefit of getting detailed information 
regarding network operation. 

As to claim 10 and 19, Elliott in view of Szabo discloses 1 and 14, but is silent on 
wherein PLR is defined as 

(lost packets + late packets) 
(received packets -§- lost packets + late packets) * 

RFC 3550 discloses, by definition, PLR is the ratio of the number of packets NOT 
received to number of the total packets sentior a given period of time (such as 
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disclosed by "The ratio of these two is the packet loss fraction over the interval" in last 
paragraph of page 43 in RFC 3550); The PLR formula above is simply a math 
expression of the definition; note that the number of packets that are NOT received 
equal to the sum of the number of lost packets and the number of last packets {last 
packets are the packets that are not received during the time interval but may be 
received at a later time). 

Therefore, it would have been obvious to a person of ordinary skill in the art at 
the time of the invention to apply the teaching of RFC 3550 above to the system 
disclosed by Elliott in view of Szabo for the benefit of calculating PLR using formula 
shown above for gaining a better understanding of network performance status. 

As to claim 20, Elliott in view of Szabo discloses claim 19, Elliott further 
discloses the traffic processing (including new call setup) depends on QoS parameters, 
including packet loss performance ([1081]); 

Elliott does not explicitly disclose the new call is accepted if PLR is below a given 
threshold; 

however, PLR is just one commonly used QoS parameter; 

therefore, it would have been obvious to a person of ordinary skill in the art at the 
time of the invention to a new call is accepted if PLR that is (calculated by the third 
circuit, CPU) is below a given threshold for the benefit of providing reliable network 
service for users. 

As to claim 21 , Elliott in view of Szabo and RFC 3550 discloses of claim 1 9, 
Elliott further discloses the third circuit compares the packet loss ratio; 
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Elliott does not explicitly disclose the new call is accepted using a reduced 
bandwidth if PRL is between given low threshold and the upper threshold; 

however, PRL is commonly used QoS parameter ([1081]); and Elliott also 
teaches providing different network services depend on QoS parameters, such as delay 
and packet loss information ([1088]); 

therefore, it would have been obvious to a person of ordinary skill in the art at the 
time of the invention to a new call is accepted using a reduced bandwidth if PRL that is 
(calculated by the third circuit, CPU) is between given low threshold and the upper 
threshold for the benefit of providing reliable network service for users. 

As to claim 22, Elliott in view of Szabo and RFC 3550 discloses claim 19. 

Elliott does not explicitly disclose the new voice call is accepted if PLR is below a 
given threshold; 

however, PLR is commonly used as a QoS parameter ([1081]); 

therefore, it would have been obvious to a person of ordinary skill in the art at the 
time of the invention to a new call is blocked if PLR that is (calculated by the third circuit, 
CPU) is above the upper threshold for the benefit of protecting normal network 
operation. 

As to claim 24, Elliott in view of Szabo discloses claim 1 , but is silent on the 
information indicative of the quality of service of voice calls being transmitted from the 
first gateway to the second gateway comprises a plurality of performance reports 
associated with the voice calls, wherein determining the congestion status parameters 
of the network paths comprises: determining, for each of the performance reports, one 
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of the network paths with which the performance report is associated; and determining, 
for each of the network paths, the congestion status parameter of the network path 
using at least a portion of the performance reports determined to be associated with the 
network path. 

RFC 3550 discloses the information indicative of the quality of service of voice 
calls being transmitted from the first gateway to the second gateway comprises a 
plurality of performance reports associated with the voice calls ("sender report (SR) and 
receiver report (RR)", 1 st paragraph of Section 6.4, page 35), wherein determining the 
congestion status parameters of the network paths comprises: determining, for each of 
the performance reports, one of the network paths with which the performance report is 
associated (SSRC_1 ... SSRC_n in SR shown in SR packet in Section 6.4.1 of page 36 
shows the network path associated with the report); and determining, for each of the 
network paths, the congestion status parameter of the network path using at least a 
portion of the performance reports determined to be associated with the network path 
(one of congestion status parameters "fraction lost", "cumulative number of packets 
lost", and "delay since last SR (DLSR)", 1 st paragraph of Section 6.4, page 35). 

Therefore, it would have been obvious to a person of ordinary skill in the art at 
the time of the invention to apply the teaching of RFC 3550 above to the system 
disclosed by Elliott in view of Szabo in order to reduce the network congestion. 

As to claim 25, Elliott in view of Szabo discloses claim 1 , but does not 
specifically discloses the information indicative of the quality of service of voice calls 
being transmitted from the first gateway to the second gateway comprises a plurality of 
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performance reports associated with the voice calls, wherein determining the 
congestion status parameters of the network paths comprises: for each of at least one 
of the network paths: selecting only a subset of the performance reports associated with 
the network path; and determining the congestion status parameter of the network path 
using the selected subset of the performance reports associated with the network path. 

RFC 3550 discloses the information indicative of the quality of service of voice 
calls being transmitted from the first gateway to the second gateway comprises a 
plurality of performance reports associated with the voice calls ("sender report (SR) and 
receiver report (RR)", 1 st paragraph of Section 6.4, page 35), wherein determining the 
congestion status parameters of the network paths comprises: for each of at least one 
of the network paths (each report is for a path): selecting only a subset of the 
performance reports associated with the network path (congestion status parameters 
"fraction lost", "cumulative number of packets lost", and "delay since last SR (DLSR)", 
1 st paragraph of Section 6.4, page 35, are a subset of the report); and determining the 
congestion status parameter of the network path using the selected subset of the 
performance reports associated with the network path (congestion status parameters 
"fraction lost", "cumulative number of packets lost", and "delay since last SR (DLSR)", 
1 st paragraph of Section 6.4.1 , page 36, are a subset of the report). 

Therefore, it would have been obvious to a person of ordinary skill in the art at 
the time of the invention to apply the teaching of RFC 3550 above to the system 
disclosed by Elliott in view of Szabo in order to reduce the network congestion. 
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As to claim 27, Elliott in view of Szabo discloses claim 26, but is silent on for 
each of at least one of the network paths, the call control logic is updated using the 
congestion status parameter for the network path periodically. 

RFC 3350 discloses for each of at least one of the network paths, the call control 
logic is updated using the congestion status parameter (one of congestion status 
parameters "fraction lost", "cumulative number of packets lost", and "delay since last SR 
(DLSR)", 1 st paragraph of Section 6.4, page 35,) for the network path periodically ("each 
periodically transmitted compound RTCP packet MUST include a report packet", 1 st 
paragraph of page 22, Section 6.1). 

Therefore, it would have been obvious to a person of ordinary skill in the art at 
the time of the invention to apply the teaching of RFC 3550 above to the system 
disclosed by Elliott in view of Szabo in order to reduce the network congestion. 

As to claim 28, Elliott in view of Szabo discloses claim 26, wherein, for each of at 
least one of the network paths, the call control logic is updated using the congestion 
status parameter for the network path on an exception reporting basis ("Sender and 
Receiver Reports", Section 6.4 page 35-45; note that Sender and Receiver Reports are 
exception reporting because they provide exception information like "fraction lost", 
"cumulative number of packets lost"). 

Therefore, it would have been obvious to a person of ordinary skill in the art at 
the time of the invention to apply the teaching of RFC 3550 above to the system 
disclosed by Elliott in view of Szabo in order to obtaining useful network information. 
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As to claim 29, Elliott in view of Szabo discloses claim 1 , Elliott further discloses 
the first gateway comprise a plurality of ports (FIG. 1 shows each gateway 1 08 and 1 1 0 
has a plurality of ports) associated with the respective plurality of network paths (FIG. 1 
shows plurality of network paths via Data network 112), for each network path: for each 
of at least one voice call being transmitted from the first gateway to the second gateway 
via the network path (as shown in FIG. 1 ). 

Elliott is silent on, computing a congestion status value associated with the voice 
call using the obtained information associated with the voice call; and determining the 
congestion status parameter of the network path using the at least one congestion 
status value computed for the network path. 

RFC 3550 discloses computing a congestion status value associated with the 
voice call using the obtained information associated with the voice call; and determining 
the congestion status parameter of the network path using the at least one congestion 
status value computed for the network path (each voice call has a path and is 
associated with the specific report that includes congestion status parameters "fraction 
lost", "cumulative number of packets lost", and "delay since last SR (DLSR)", 1 st 
paragraph of Section 6.4.1 , page 36). 

Therefore, it would have been obvious to a person of ordinary skill in the art at 
the time of the invention to apply the teaching of RFC 3550 above to the system 
disclosed by Elliott in view of Szabo in order to obtaining useful network information. 

As to claim 30, Elliott in view of Szabo claim 29, but is silent on the congestion 
status parameter for the network path is determined by selecting the congestion status 
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value computed for the network path that is indicative of the greatest amount of 
congestion on the network path 

RFC 3550 discloses the congestion status parameter for the network path is 
determined by selecting the congestion status value computed for the network path that 
is indicative of the greatest amount of congestion on the network path (each voice call 
has a path and is associated with the specific report that includes congestion status 
parameters "fraction lost", "cumulative number of packets lost", and "delay since last SR 
(DLSR)", 1 st paragraph of Section 6.4.1 , page 36; e.g., select the greatest amount of 
delay because all other delay value is irrelevant anymore). 

Therefore, it would have been obvious to a person of ordinary skill in the art at 
the time of the invention to apply the teaching of RFC 3550 above to the system 
disclosed by Elliott in view of Szabo in order to obtaining useful network information. 

As to claim 31 , Elliott in view of Szabo claim 1 , but is silent on the determination 
as to whether to accept the new call into the network at the first gateway is performed 
using all of the network congestion parameters. 

RFC 3550 discloses the determination as to whether to accept the new call into 
the network at the first gateway is performed using all of the network congestion 
parameters (each voice call has a path and is associated with the specific report that 
includes congestion status parameters "fraction lost", "cumulative number of packets 
lost", and "delay since last SR (DLSR)", 1 st paragraph of Section 6.4.1 , page 36; all 
these parameters can be used for determination as to whether to accept the new call 
into the network). 
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Therefore, it would have been obvious to a person of ordinary skill in the art at 
the time of the invention to apply the teaching of RFC 3550 above to the system 
disclosed by Elliott in view of Szabo in order to obtaining useful network information. 

As to claim 32, Elliott in view of Szabo and RFC 3550 discloses claim 31 , Elliott 
further discloses on accepting the new call into the IP network at the first gateway for 
transmission toward the second gateway via one of the network paths (as disclosed by 
the parent claims 1 ; note that the new call is always accepted via one the network 
paths), wherein the one of the network paths for the new call is the one of the network 
paths having the associated congestion status parameter indicative of the least amount 
of congestion (as disclosed by the parent claims 1 : claim 1 discloses congestion 
information for different paths among which there is one path that has the least amount 
of congestion). 

Claims 2 and 13 are rejected under 35 U.S.C. 103(a) as being unpatentable over 
Elliott in view of Szabo, further in view of Watt (US Patent number 5781 532, hereinafter 
Watt). 

As to claim 2, Elliott in view of Szabo discloses the method of claim 23, but are 
silent on wherein new call may be accepted at a reduced bandwidth in the case of said 
parameter exceeding a lower threshold. 

In the same field of endeavor, Watt discloses adjusting transmission rate in 
response to a "mild" congestion state, as indicated by the value packet loss ratio 
exceeding a lower threshold but below an upper threshold, "adjusting the transmission 
rate in response to the detection of said congestion ... when the detected congestion 
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exceeds a predetermined mild congestion threshold', from line 21 of col. 7 to line 3 of 
col. 8). 

Therefore, it would have been obvious to a person of ordinary skill in the art at 
the time of the invention to accept a new call at a reduced bandwidth in order to fully 
take advantage of network resource. 

As to claim 13, Elliott in view of Szabo and Watt discloses the method of claim 2, 
Elliott disclose further discloses wherein the bandwidth of a newly accepted call is 
reduced by activating the characteristic of silence suppression for said newly accepted 
voice call (silence suppression activation timer, table 147 in Page 85). 

Claims 11-12 are rejected under 35 U.S.C. 103(a) as being unpatentable over 
Elliott in view of Szabo and Watt, further in view of RFC 3550. 

As to claim 11 , Elliott in view of Szabo and Watt discloses claim 2, Elliott further 
discloses using different encoders (CODECS, such as ones supporting G.71 1 , G. 726, 
and G.728 in [1004]) to handle different connections with different bandwidth ([1004]); 
which include the case of using 2 different encoders to handle 2 different kinds of calls 
that have different bandwidth. 

As to claim 12, Elliott in view of RFC 3550 and Szabo discloses the method of 
claim 2, but are silent on wherein the bandwidth of a newly accepted call is reduced by 
increasing the packet size for said newly accepted voice call. 

However, for a given amount of data, increasing the packet size will decrease the 
overhead caused by packet header therefore reduce the required bandwidth for the call, 
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(this is demonstrated by efficiency factor e=(packet_size)/( packet_size+header_size); 
for a fixed header size, the larger is the packet_size, the larger is e); 

Therefore, it would have been obvious to a person of ordinary skill in the art at 
the time of the invention to increase the packet size so as to decrease the required 
bandwidth for the call for the benefit of saving bandwidth resource. 

Claims 16-17 are rejected under 35 U.S.C. 103(a) as being unpatentable over 
Elliott in view of RFC 3550 and Szabo, further in view of Hooper et al (US 20040252686 
A1) (hereinafter Hooper). 

As to claim 16, Elliott in view of Szabo discloses the apparatus of claim 14, but 
are silent on said second circuit is at least one strongarm card. 

However, the second circuit is simply a CPU card (such as CPU card of Soft 
Switch 204, FIG. 2B) that implement the logic of receiving QoS information associated 
with voice calls, and strongarm is a popular CPU that is commonly used in the CPU 
cards as disclosed by Hooper ("the core processor implemented as a Strong Arm 
architecture", [0010]). 

Therefore, it would have been obvious to a person of ordinary skill in the art at 
the time of the invention to use strongarm CPU card as the circuit disclosed by Elliott for 
the benefit of cost saving. 

As to claim 17, Elliott in view of Szabo and Hooper discloses the apparatus of 
claim 16, Elliott further discloses the CPU card (with strongarm CPU) is connected to 
the Ethernet card via a host CPU circuit (CPU card of Soft Switch 204 is connected to 
Ethernet switches 332, [0568], line 1-5 and FIG. 2B). 
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(10) Response to Argument 

The following are Examiner's responses to some of Appellant's arguments. 

For Appellant's arguments of I (page 7-9), regarding rejection of claim 1 under 
1 1 2, first paragraph, Appellant argues the text starting from line 27 in page 6 of the 
specification discloses the limitation "each of said network paths being associated with 
respective first gateway egress interfaces and a second gateway system IP address". 

In response, Examiner respectfully disagrees. The specification text starting 
from line 27 in page 6 and the relevant Figures showing the first gateway 1 14 are 
recited as follows: 

In this framework, load balancing is supported by controlling the egress port at the source 
gateway (i.e., first gateway 114). Since each egress port would map into a unique path in the IP 
network 118, the load from source gateway 114 to a destination gateway (i.e., second gateway 116) can 
be partitioned into different paths, resulting in load sharing in the network. 
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FIG, 2 



The text "each egress port would map into a unique path" clearly discloses that 
each path may only be mapped into one interface/port. Each path can only be 
"associated" with one interface/port at an end gateway (such as gateway 1 14 or 1 16), 
NOT multiple interfaces/ports, as shown in FIG. 2 above. The cited text clearly 
teaches that a load can be partitioned, but not a path. Therefore, the cited claim 
limitation is not supported in the specification. In fact, the claim limitation "each of said 
network paths being associated with respective first gateway egress interfaces and a 
second gateway system IP address" is inconsistent with the common understanding of 
one of ordinary skilled in the art because each interface/port may have only a unique IP 
address, and multiple interfaces/ports normally do on share a single IP address. 
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Furthermore, Appellant did not even response to the 1 12 rejection in the non final 
office action. Appellant responses to the 1 12 rejection only in this appeal brief for the 
first time, which is not consistent with the guideline according to MPEP. 

For Appellant's arguments of II, regarding rejection of 1,3,5,14-15,18,23,26 
and 33 under 103(a): 

a) A.1 for claim 1 , Appellant appears to argue that the claim limitation 
"congestion status parameters" are equivalent to "packet loss ratio, delay and 
interarrival jitter" because the specification defines so; and Examiner's interpretation of 
the claim limitation "latency or packet loss are parameter related to the congestion 
status of the network" is wrong because they do not include all the "congestion status 
parameters" which inlcude packet loss ratio, delay and interarrival jitter (see page 12); 
and the motivation of combining Elliott with Szabo fails to have some rational to support 
the legal conclusion of obviousness (page 14-15). 

In response, Examiner respectfully disagrees. First, the contents in specification 
can not be read into the claim according to MPEP. Second, nowhere in the specification 
does define that "congestion status parameters" are equivalent to "packet loss ratio, 
delay and interarrival jitter". The only place disclosing "packet loss ratio, delay and 
interarrival jitter" in the specification (in paragraph [0030] of the application publication) 
is cited as follows: 

destination gateway 116 receives the RTP packets generated by the source gateway 114 (e.g., at 
port E2) and addressed to itself. For each RTP stream, the receiver measures call quality statistics like 
packet loss ratio, delay and interarrival jitter for the stream. The measured statistics are sent back to 
the source gateway 1 14 periodically in a special field within the RTP packets or in RTCP packets. 
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It is clear that "congestion status parameters" is not defined in the specification. 
The specification teaches that "packet loss ratio, delay and interarrival jitter" are simply 
examples of the "call quality statistics like" parameters, not the congestion status 
parameters as argued by Appellant. Furthermore, interpreting "latency or packet loss" to 
be congestion parameters as cited in the final office action is reasonable because 
"latency or packet loss" show the congestion status (long latency or packet loss are 
indication of network congestions). 

As to the motivation, the final office action clearly states "to apply Szabo's 
teaching above to the gateways disclosed by Elliott for the benefit of ensuring 'a 
transmission path with acceptable transmission quality' ([0008] of Szabo)", in which 
the benefit of combining is clearly stated. Elliot discloses general network operation 
related to congestion, while Szabo discloses more details information on how to handle 
specific network congestion. Ordinary skilled in the are would be motivated to apply the 
teaching of Szabo on the network congestion to the general network disclosed by Elliot 
in order to provide more detailed information on how to handle specific network 
congestion. 

b) A.2 for claim 14 (page 16), Appellant makes an argument based on claim 1 , to 
which Examiner's response is the same as with claim 1 . 

c) A.3 for claim 3,5,15,18,23,26 and 33 (page 16), Appellant makes an argument 
based on claim 1 , to which Examiner's response is the same as with claim 1 . 
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d) A.4 for claims 2,4,6-13,16-17,19-22,24-25 and 27-32 (page 17), Appellant 
makes an argument based on claims 1 and 14, to which Examiner's response is the 
same as with claims 1 and 14. 

(11) Related Proceeding(s) Appendix 

No decision rendered by a court or the Board is identified by the examiner in the 
Related Appeals and Interferences section of this examiner's answer. 

Conclusion 

For the above reasons, it is believed that the rejections should be sustained. 
Respectfully submitted, 
/Jianye Wu/ 

Primary Examiner, Art Unit 2462 

/Xavier Szewai Wong/ 

Primary Examiner, Art Unit 2462 

/Seema S Rao/ 

Supervisory Patent Examiner, Art Unit 2462 



